The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Software applications are often large and complicated, and after creating a new application, the software producers continue to make modifications, improvements, and add new features to the application. As a result, applications that are typically installed at a large number of customer locations periodically need to be upgraded to include such changes. The upgrading of an installed application in the field at a customer location generally involves taking down the current installation of the application, performing the upgrade to the application in the form of making modifications to one or more features of the current software installation or installing one or more new features, and then bringing back up the upgraded application for subsequent use by the customer.
However, there are several drawbacks with this approach to upgrading applications. For example, the installed software is unavailable for use while the upgrade is being performed, which is referred to as “downtime.” Often the downtime for performing an upgrade is sufficiently long that special arrangements must be made by the customer so that making the upgrade does not adversely impact the customer's normal business operations that involve the use of the application being upgraded.
As another example, whenever an application is taken down, there is a risk that the application will not be returned for use on time or that the application will work properly after the upgrade is performed. The larger the software application and the greater the number of changes being made as part of an upgrade, the more fragile the application and therefore greater the risk that the application will not be returned to operation on time and that there will not be subsequent problems arising from the upgrade. Sometimes the risk of problems arising from making an upgrade is sufficiently great to cause a customer to delay or even forgo the upgrade to avoid the risk of an unacceptable interruption in the customer's normal business operations.
As yet another example of the problems with making application upgrades, upon completion of a successful upgrade, the new features that have been added via the upgrade to the application are often poorly integrated or not integrated at all with existing features of the application. The lack of integration is intended to reduce downtime and minimize risk by limiting the scope and complexity of the upgrade. For example, if the upgrade includes adding a new feature, the newly added functions for the new feature typically can only be used by themselves as part of the new standalone feature. However, customers often want to be able to use newly added features with preexisting features, and the lack of integration between new and preexisting features limits the usefulness of the new features.
In order to use new features with other preexisting features of the software application, modifications to those preexisting features would be required, which increases the complexity of the upgrade with an associated increase in downtime and risk. For example, a preexisting feature would need to be modified to work with the newly added feature as part of the upgrade to the software application to allow the preexisting feature to incorporate the new functions from the newly added feature.
While modifying one preexisting feature to work with one newly added feature is usually not a significant problem, software applications typically include dozens or hundreds of features. As a result, upgrades typically involve adding a significant number of new features that customers would like to have integrated with each other and the preexisting features. Due to the exponential increase in the complexity of the upgrade that would be involved in integrating all new features with the preexisting features, upgrades often allow newly added features to be used in a stand-alone fashion or with very limited integration with the preexisting features.
Another problem with using limited upgrades for application is that, from the user's perspective, the upgraded application suffers from a problem known as the “silo effect” because the newly added features can only be used separately from other preexisting features. Even if the upgrade does attempt to incorporate some integration of new features with an preexisting features, the integration is typically very limited and as a result, the customer can easily see that the new features were newly added as part of an incremental upgrade because the new features are not well integrated with the preexisting features. This result tends to lesson the customer's perceived value of undertaking the upgrade and reduces the customer's willingness to incur the associated downtime and risk of making the upgrade.